UTRAN (Universal terrestrial radio access network) is a term that identifies the radio access network of a UMTS (Universal Mobile Telecommunications System), wherein the UTRAN consists of Radio Network Controllers (RNCs) and NodeBs i.e. radio base stations. The NodeBs communicate wirelessly with mobile user equipments and the RNCs control the NodeBs. The RNCs are further connected to the Core Network (CN). Evolved UTRAN (E-UTRAN) is an evolution of the UTRAN towards a high-data rate, low-latency and packet-optimised radio access network. Further the E-UTRAN does only consist of eNodeBs (evolved NodeBs), and the eNodeBs are interconnected and further connected to the Evolved Packet Core network (EPC). E-UTRAN is also being referred to as Long Term Evolution (LTE) and is standardized within the 3rd Generation Partnership Project (3GPP).
In E-UTRAN, the uplink MAC (Media Access Control) scheduler resides in the eNodeB and assigns transmission resources, i.e. resource blocks, to user equipments associated with the eNodeB. Furthermore, the MAC scheduler selects the Transport Format (TF) to be used by the user equipment. Although the MAC scheduler controls the payload of a scheduled user equipment, the user equipment is responsible for selecting from which radio bearer the data is taken. Thus, the user equipment has an uplink rate control function which manages the sharing of uplink resources between radio bearers. RRC (Radio Resource Control) controls the uplink rate control function by giving each bearer a priority and a prioritized bit rate (PBR). The user equipment performs the radio-bearer multiplexing by serving the radio bearers in priority order up to their configured PBR. Remaining resources assigned by a grant, after fulfilling the PBR, are given to the radio bearers in priority order. In case the PBRs are all set to zero, the first step is skipped and the radio bearers are served in strict priority order i.e. the user equipment maximises the transmission of higher priority data.
In order to assign transmission resources and select the TF the MAC scheduler needs information about the current buffer state of the user equipment, i.e. if and how much data the user equipment buffers in its priority queues. The MAC scheduler may also need further information such as the available power headroom or the transmit power in order to estimate the uplink gain and to select a suitable TF for the user equipment. Very precise and up-to-date scheduling information allows accurate scheduling decisions. However, providing this information from the user equipment towards the eNodeB comes at a certain cost which must be compared to the gain it offers.
It is likely that any buffer information received in the MAC scheduler will be outdated when it is to be used in the scheduling decision. New data may have arrived in the user equipment for a radio bearer (RB) with higher priority than current buffered data, or data may have been dropped from the buffer of the user equipment due to delay constraints. However, without any additional information the MAC scheduler has no indication if the previously scheduled grant was enough or if a large amount of data is still left in the buffer of the user equipment. A too large grant results in padding, which may reduce the system capacity, whereas a too small grant causes extra delay. A situation wherein this balance needs to be considered is high load situations close to the capacity limit. In this situation frequent uplink signalling of buffer occupancy will consume uplink capacity. Therefore, the frequency of signalling has to be weighted to the need of carefully scheduling each user equipment and implicitly each RB appropriately.
3GPP has specified a framework 3GPP TS 36.321 “Medium Access Control (MAC) protocol specification” for buffer status reporting. Buffer status reporting is used by the user equipment to report to the eNodeB the amount of data available for transmission that is stored in its buffers. The MAC scheduler uses these reports to allocate resources to the user equipment, and to prioritize resource allocation between different user equipments. Buffer Status Report (BSR) and Scheduling Request (SR) are triggered when uplink data arrives in the user equipment transmission buffer and the data belongs to a radio bearer group, i.e. a logical channel group, with higher priority than those for which data already existed in the buffer of the user equipment. With this type of triggering, the MAC scheduler can quickly be made aware when data with higher priority is available for transmission, without excessive reporting. It has also been agreed to introduce a periodic timer-based trigger BSR per user equipment to handle reporting for a continuous flow. However, the periodic BSR does not trigger BSR.
The BSR is defined as MAC Control Elements as pictured in FIG. 1 in LTE. The BSR Control Element consists of either a short BSR format, i.e. one LCG ID (Logical Channel Group Identity) field and one corresponding Buffer Size (BS) field shown in FIG. 1a or a long BSR format, i.e. four Buffer Size fields, corresponding to LCG IDs #1 through #4 as shown in FIG. 1b. The LCG ID field identifies the group of logical channel(s) for which buffer status is being reported. The BS field identifies the total amount of data available across all logical channels of a logical channel group after the MAC PDU has been built.
FIG. 2 illustrates a MAC PDU (Protocol Data Unit) consisting of a MAC header, MAC Control Elements, MAC SDUs (Service Data Units), and padding. A MAC PDU consists of a MAC header, zero or more MAC SDU, zero or more MAC Control Elements, and optionally padding. Both the MAC header and the MAC SDUs are of variable sizes. A MAC PDU header consists of one or more MAC PDU sub-headers; each sub-header corresponding to either a MAC SDU, a MAC Control Element or padding.
MAC PDU sub-headers have the same relative position order as the corresponding MAC SDUs, MAC Control Elements and padding have in the MAC PDU. MAC Control Elements are always placed before any MAC SDU. A maximum of one MAC PDU can be transmitted per Transport Block (TB) per user equipment. Depending on the physical layer category, one or two Transport Blocks can be transmitted per transport time interval (TTI) per user equipment.
The BSR framework previously described is sensitive to error cases due to HARQ (Hybrid Automatic Repeat-Query) failures e.g. NACK to ACK errors. These error cases can be recovered with the periodic timer-based trigger, but only to some extent and only when the user equipment gets a grant. Thus, detailed BSR sent in MAC CE is sensitive to HARQ errors and failures.
The BSR sent in MAC CE reports the amount of data in the buffers for one (short format) or four (long format) groups of logical channels, i.e. for one LCG or all four LCGs, respectively. The short BSR format is 1 byte, and the long format is 3 bytes as shown in FIGS. 1a and 1b. Assuming that the MAC header requires only a LCID and an E field, and that the L field can be omitted because the BSR CE has a fixed length, these 6 bits lead to one additional byte in the MAC header and thus the total overhead for each MAC PDU that carries a BSR is 2 bytes or 4 bytes, respectively.
The BSR framework requires a careful tuning of the triggering parameters to avoid excessive overhead. In the case where the UE transmission buffers are continuously filled with data, the scheduler typically needs frequent BSRs. For continuous flows, the timer-based approach will ensure that BSRs will be sent periodically. Parameter tuning depends on the characteristics of the traffic, which are difficult to predict. The frequency of the BSR will typically be configured for the worst-case traffic behaviour. However, when a detailed BSR is transmitted frequently, the number of bits of overhead is costly.
The eNodeB can configure semi-persistent resources for a user equipment, e.g. when a radio bearer carrying a VoIP service is setup. A semi-persistent resource assignment is valid for as long as more data is sent within a predetermined time period of last sent data and expires if no data is sent within the predetermined time period The resources are typically configured to match the bit rate of the service and the radio characteristics, taking into account the header compression if header compression is configured. The following events trigger a BSR in the above scenario:                RTCP (Real-Time Transport Control Protocol) arrives in the user equipment transmission buffer i.e. new data with the same or lower priority;        Header compression does not produce the smallest header size.        
If the user equipment only has semi-persistent resources allocated at the time the event occurs, the user equipment would then send the regular BSR using the semi-persistent resource together with some of the data, e.g. a segment of a speech frame. The eNodeB can then allocate additional dynamic resources for the remainder of the data in the buffers of the user equipment. It could be desirable to avoid this overhead and to have the possibility to not send the BSR. A low-cost small buffer status report that indicates that the user equipment has more data to send simplifies semi-persistent scheduling. It is useful for the eNodeB to have as accurate buffer status as possible, to prioritize resource allocations between user equipments, and to decide how much resources to allocate when scheduling a user equipment.
Buffer Status Reporting may represent quite a large number of bits. If BSR is transmitted frequently, this could represent a considerable overhead. Many applications, e.g. TCP, continuously increase and decrease their congestion window e.g. when experiencing a packet drop. The buffer status is continuously changing and a rough buffer indication that is frequently updated is more useful than a detailed BSR.